Update GoodFET to resolve packet concatenation and fix the sync problem#216
Update GoodFET to resolve packet concatenation and fix the sync problem#216inode- wants to merge 5 commits into
Conversation
… the second parts of the packets.
…t=2 will caus to not identify the apiMote. An alternative is to launch before the commands a goodfet client (which doesn't have the attempt limit) and then use killerbee goodfet/client/goodfet.monitor listapps full
…a fix for the ACK not recived correctly. Updated python will work with both, new firmware or old firmware. The compiled firmware has also a patch to work correctly (see pull request 51 on goodfet repositoty)
inode-
changed the title
|
|
||
| #Set up the radio for ZigBee | ||
| self.strobe(0x01); #SXOSCON | ||
| self.strobe(0x01); #SXOSCON ## YL: idk why but needed to enable ram poking |
There was a problem hiding this comment.
@travisgoodspeed - this appears that this PR just updates code from GoodFET repo, do you have insight into this change as the comment makes me wonder about it? https://github.com/travisgoodspeed/goodfet/blob/master/client/GoodFETCCSPI.py#L22
|
|
||
| lastpacket=range(0,0xff); | ||
|
|
||
| def RF_txrxpacket(self,packet,timeout=1): |
There was a problem hiding this comment.
Using this for zbstumbler type use cases may be helpful to get a potentially quicker RX to a forged beacon request? CC @taylorcenters
| In case of problems identifying the hardware try to run the following command (present in [GoodFET](https://github.com/travisgoodspeed/goodfet/blob/master/firmware/apps/radios/ccspi.c)) before any killerbee command | ||
|
|
||
| `~/goodfet/client$ sudo ./goodfet.monitor listapps full` | ||
|
|
There was a problem hiding this comment.
We're going to move this to the FAQs if that's OK. @taylorcenters is preparing the update off of this PR that includes that.
| from scapy.base_classes import SetGen | ||
| from scapy.packet import Gen, Raw | ||
| from scapy.all import * | ||
| from scapy import plist |
|
The new firmware use the latest version of GoodFET which doesn't concatenate to the data packets the ACK. This kind behavior was the cause of "Bad FCS" that a lot of people was having with ApiMote. The other problem was that a lot of people need to detach and attach multiple time the ApiMote to get it working. Fixed in the python code. Also the workaround was another way to "bypass" the sync problem. Other minor fixes was done. |
|
@inode- This branch has merge conflicts with develop, probably caused by the Python 3 changes now merged there. Do you have any capacity to resolve these conflicts? I'm terribly excited to see the Bad FCS issue go away. Thanks for this patch! |
|
I'll take a shot at adding this patch for the current py3 version of kb in a new PR |
|
Please check out #229 for this change made for python3. I will probably rebuild the apimote firmeware and add it there too - Might be worth trying to set up some github pipeline that will build it and make an artifact available rather than just uploading compiled firmware. |
|
Thanks so much for this PR. The change got merged in with #229 |
4 participants
Using an old version of GoodFET caused problems in receiving ACK packets that were concatenated with data packets.
I made a patch for GoodFET which fixes some problems of the latest versions (travisgoodspeed/goodfet#51) and compiled the current version which no longer has the chained ACK problem.
I also increased the "attemptslimit" parameter so that serial sync can be done correctly. An alternative is to do it manually with the command:
goodfet/client/goodfet.monitor listapps fullThis patch is expected to fix several bugs, in particular:
#215
#192
#190
#166
#160
#159
#155